packages/webviewer/src/adapter.ts (1)

145-149: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Guard empty messages before reading code.

resp.messages?.[0].code still dereferences .code when messages is an empty array, so malformed FileMaker envelopes reject with a TypeError instead of the intended FileMakerError.

Proposed fix

   private handleDataApiResponse(resp: clientTypes.RawFMResponse): unknown {
-    if (resp.messages?.[0].code !== "0") {
+    const code = resp.messages?.[0]?.code ?? "500";
+    if (code !== "0") {
       throw new FileMakerError(
-        resp?.messages?.[0].code ?? "500",
-        `Filemaker Data API failed with (${resp.messages?.[0].code}): ${JSON.stringify(resp, null, 2)}`,
+        code,
+        `Filemaker Data API failed with (${code}): ${JSON.stringify(resp, null, 2)}`,
       );
     }

As per coding guidelines: “Use optional chaining (?.) and nullish coalescing (??) for safer property access.”

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/webviewer/src/adapter.ts` around lines 145 - 149, The FileMaker
response check in handleDataApiResponse still reads code from resp.messages?.[0]
without guarding the case where messages is an empty array, which can throw a
TypeError before FileMakerError is raised. Update the resp.messages validation
to safely handle both missing and empty messages using optional chaining and
nullish coalescing, and keep the FileMakerError construction in
handleDataApiResponse as the single failure path when the first message code is
not "0" or is unavailable.

Source: Coding guidelines

packages/webviewer/src/adapter.ts (2)

251-271: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Keep internal batch IDs authoritative.

{ id: request.id, ...request.payload } lets a top-level id from body overwrite the queue id, causing response mapping to miss the result. Put id last; using for...of also matches the TS iteration guideline.

Proposed fix

-      const resp = await fmFetch<BatchScriptResponse>(this.scriptName, {
+      const batchRequests: Array<DataApiScriptRequest & { id: string }> = [];
+      for (const request of requests) {
+        batchRequests.push({
+          ...request.payload,
+          id: request.id,
+        });
+      }
+
+      const resp = await fmFetch<BatchScriptResponse>(this.scriptName, {
         batch: true,
-        requests: requests.map((request) => ({
-          id: request.id,
-          ...request.payload,
-        })),
+        requests: batchRequests,
       });

As per coding guidelines, **/*.{ts,tsx}: “Prefer for...of loops over other iteration methods.”

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/webviewer/src/adapter.ts` around lines 251 - 271, In the batch
request construction inside the adapter’s fmFetch call, the queued request id is
being overwritten by request.payload, which can break response mapping. Update
the request object assembly so the internal queue id remains authoritative by
ensuring the id field is applied last, and switch the requests mapping in this
batch path to a for...of-based build to follow the TS iteration guideline.

Source: Coding guidelines

---

224-230: 🚀 Performance & Scalability | 🟠 Major | 🏗️ Heavy lift

Keep new arrivals on their own batch window.

drainBatchQueue() keeps looping until the queue is empty, so requests enqueued while the current fmFetch is in flight can be sent immediately when that call returns, before their windowMs timer expires. Snapshot the queue for the current flush, and let later arrivals flush via their own timer/max-size path.

Also applies to: 237-245

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/webviewer/src/adapter.ts` around lines 224 - 230, The batching logic
in batchFlushInProgress/flushBatchQueue/drainBatchQueue is reusing the live
queue, which lets requests added during an in-flight fmFetch get flushed too
early. Change the flush path to snapshot the current batch at the start of
flushBatchQueue and have drainBatchQueue process only that snapshot, so later
arrivals remain queued and wait for their own windowMs timer or max-size trigger
before sending.

packages/webviewer/src/adapter.ts (1)

200-205: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Use safe optional chaining for malformed message arrays.

messages?.[0].code still dereferences .code when messages is an empty array, so malformed script/batch responses throw TypeError instead of the intended FileMakerError.

Proposed fix

-    if (resp.messages?.[0].code !== "0") {
+    const messageCode = resp.messages?.[0]?.code;
+    if (messageCode !== "0") {
       throw new FileMakerError(
-        resp?.messages?.[0].code ?? "500",
-        `Filemaker Data API failed with (${resp.messages?.[0].code}): ${JSON.stringify(resp, null, 2)}`,
+        messageCode ?? "500",
+        `Filemaker Data API failed with (${messageCode}): ${JSON.stringify(resp, null, 2)}`,
       );
     }

As per coding guidelines, use optional chaining (?.) and nullish coalescing (??) for safer property access.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/webviewer/src/adapter.ts` around lines 200 - 205, The error handling
in handleDataApiResponse still directly reads resp.messages?.[0].code, which can
throw on malformed or empty messages arrays before FileMakerError is raised.
Update the message code access to use safe optional chaining and nullish
coalescing throughout the FileMakerError branch so adapter.ts handles missing
first entries without TypeError while preserving the intended fallback status
code and message.

Source: Coding guidelines